In many systems where a computer controls an instrument, item of test equipment or some other device, the control is exerted over a bus, such as that defined by the various versions of IEEE 488 (sometimes referred to as HP-IB or as GP-IB). Compared to the older technique of using a dedicated interface card per instrument, such a bus architecture is attractive for a number of reasons, including the flexibility and expandability that arise because of the notion of addressability that is incorporated in bus operations.
Now let us suppose that there were a first collection of instruments, test equipment or other devices, all having suitably different addresses on the bus and that cooperate with a controlling program executed by a computer that is also connected to the bus, to accomplish some useful end. Perhaps the desired result is a listing or plot of the return loss as a function of frequency for a microwave attenuator; the particular nature of the example is of no special concern. We shall term this assemblage a "first collection of equipment". Present in addition to the equipment that is on one side of the bus, are the computer itself and an interface that connects the bus to the computer. The control program executed by the computer has the necessary algorithmic content for whatever overall task or tasks that are to be performed. A collection of equipment and its control program create a "context".
Now further suppose that the task at hand is one that is of a production nature, where volume of work accomplished is important, as opposed to a laboratory setting where inquiry or demonstration is the primary goal. One way to increase the overall throughput is to duplicate the entire system, including another computer and bus interface. But upon brief reflection, you may well reply "Phooey, we have a multi-tasking operating system here running on a high powered workstation. There ought to be a way to avoid needing a second computer!"
There is a conventional way to avoid that need, and it is to equip the existing computer with a second bus interface, connect a second collection of equipment to it with a second run of bus cabling, and then control the second collection with a second instance of the control program. This works, but it requires an extra bus interface and set of cabling for each additional collection of equipment. Even if you were to bear the expense of, say three additional sets of stuff, you may well discover that the card cage of the computer hasn't the number of slots needed to accommodate the extra cards, given any other cards that may need to be there, too.
At this point one might consider putting all the collections on the same bus, with each collection operating within a unique portion of the bus address space. Then the different instances of the control program are each informed of the particular set of addresses they are to deal with. This avoids multiple instances of the bus interface, but to your ultimate annoyance, it is a real dog in terms of speed. It appears as if things are happening in serial fashion instead of in parallel.
Upon reflection it is clear what the problem is. Let us assume that each collection has a particular instrument therein, a voltmeter, say, and that one of the requested measurements of each of those voltmeters requires a significant amount of time. The essence of the problem is that bus controlled instruments are prone to tying up the bus for the duration of their response to a command. By this we mean that during the "significant amount of time" when one of those voltmeters is doing that "long" measurement the bus interface in the computer is not free to send commands to or receive data from other instruments on the bus; it must wait until the long measurement is complete and the results transmitted over the bus as data. (In the case of HP-IB there is an "@ address listen" followed by an instruction, which is then followed immediately by an "@ address talk" that requests the data. This period of waiting until the data comes back is what ties up the bus interface.) Thus it is that all the long waits are executed serially, rather than being overlapped. And while this would not be a problem if there were just the one collection (the measurement/control algorithm for each collection considered individually is probably serial within its own context, anyway), it does become a problem when the delays of one collection become visible in the execution of the control program for another collection.
Upon further reflection it will be appreciated that the above described situation can arise even when the various collections are not the same, and even have different controlling programs. The problem of delays that are visible outside their own contexts will still arise. That is, unless something is done to prevent it, the various delays will arrange themselves serially, and thus lower the overall rate of algorithmic execution.